The invention relates generally to computer systems, and more particularly to improvements in security for computer systems.
Historically, executable content could only installed on a computer system by physically bringing magnetic media to the computer and having someone with administrative privileges install it. At present, however, the Internet has made it very easy and popular for ordinary computer users to download executable content such as programs, HTML pages and controls. In many cases, executable content may be downloaded and executed via the Internet without the user even realizing that such an event took place. Similarly, computer users may receive electronic mail or news containing files that include executable content, such as executable programs and/or documents containing macros, and moreover, the mail or news itself may be an HTML page. Opening such a message or an attachment therein exposes the recipient""s system to whatever executable content is present.
Unfortunately, such executable content is often unruly, e.g., it may be malicious and intentionally destroy data on the client machine, error-prone and cause the client machine to crash, or well-intentioned but careless and divulge confidential information about the client. Although these types of computer problems have previously existed in the form of xe2x80x9cvirusesxe2x80x9d and xe2x80x9ctrojans,xe2x80x9d the ubiquitous presence of World Wide Web has made these problems widespread, and in some cases out of control.
On the server side, web servers launch server programs such as CGI scripts on behalf of clients and return data from the programs back to the clients. The source of such scripts is not necessarily carefully controlled, nor are all such scripts well written. As a result, poorly written CGI scripts have caused web server machines to crash or to slow down by using too many computer resources. Moreover, poorly written server programs may be tricked by a malicious client into performing actions it should not do, such as executing other applications or writing or reading data to or from storage. Lastly, some web servers even allow a client program to send scripts to the server to be executed on the client""s behalf, posing many dangers.
In general, client and server operating environments are not adequately protected against unruly executable content. At the same time, because so much executable content is valuable, the need to be able to receive and run executable content continues to grow despite the inherent risks of untrusted content.
Briefly, the present invention provides restricted execution contexts for untrusted content (such as executable code, dynamic HTML, Java or Active-X controls) that restricts the resources that the content may access. A restricted process is set up for untrusted content, and any actions attempted by the content are subject to the restrictions of the process, which are based on various criteria. Whenever a process attempts to access a resource, a restricted token associated with each process is compared against security information of the resource to determine if the type of access is allowed. The resource""s security information thus determines whether a process, and thus the untrusted content, may access the resource, and if so, the type of access that is allowed.
Untrusted content includes data downloaded from websites, and each such site has a restricted process set up therefor based on the site identity and the zone in which the site is categorized. APIs and helper processes enable the website to access its own site, files and registry keys, while ACLs on other resources not related to the site restrict the access of that site as desired, based on the site identity, zone or other criteria. Other untrusted content includes electronic mail messages or news along with any attachments thereto. Such content is similarly run in a restricted execution context wherein the restrictions are based on criteria such as the identity of the sender. Servers also may run untrusted content such as scripts and client processes in restricted execution contexts, whereby the restrictions may be based on criteria such as the script author, the method of client authentication used, and/or any other information available to the server indicative of how trusted or untrusted the content may be.
Other advantages will become apparent from the following detailed description when taken in conjunction with the drawings, in which: